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begin by/ criticizing the current generation of lan- 
guages for the /construction of knowledge- based systems as 
being at too Uiw a level of abstraction/ the 
need for higher level languages for building problem solv- 
ing systems/ We*- introduce mrrffi lotion of generic infor- 
mation processing tasks in know [edge- based problem solv- 
ing, and dm c r i b e^a toolset which can be used to build rx- 
systems in way that enhances intelligibility and 
productivity in knowledge acquisition and system construe 
lion. W j. il lu » t f i4 e ihe power of these ideas s£y paymi 
inattention to Vigh "level- language called DSPL. 
aoiiUdMBsibe^how it was used in the construction of a sys- 
tem called MPA, which assists with planning in the 
domain of offensive counter air missions. 
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that rules of medicine are not per se matters of A! 
research. That is, the content of the knowledge base itself 
is made up of domain particulars. At the same time the 
language in which the rule system is written, e.g.. Lisp, is 
typically thought of as an implementation-level detail, of 
no particular interest as A I. 
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is intended to be an introduction to the 
generic taslls approach to analyzing knowledge systems, 
descriptions l of some of the particular generic tasks that 
have been Identified, and a description of the software 
tools that have been build as a result. The approach is 
illustrated bu discussing a particular mission-planning sys- 
tem, MPA, which was built using the DSPL language (or 
tool). The intent of the paper is primarily tutorial, much 
of the material is summary or repetition of material al- 
ready presented elsewhere. 1, i 

' ///pi/r 

Level of Absti rtlon Problem In Characterizing 
Knowledge- B a d Systems 


Much of A I 
Grail” of a level 
havior qua intelligi 
presumably, are 


domain, and below 
the intelligent level 
rule-based system su 



The AI interest of a given expert system is often a mat* 
ter of the level at which it is viewed. Clearly, taking 
Mycin as an example, all the following points of view are 
correct: (i) it suggests therapy for certain kinds of infec- 
tious diseases, (ii) it is an embodiment of a diagnostic and 
therapeutic strategy, and (iii) it is a decision-maker which 
uses backward chaining to navigate a knowledge base of 
ules, connecting pieces of evidence to conclusions, in order 
lo arrive at a reliable conclusion from a given set of data. 

] Joint of view (i) is of limited interest to Al. and point of 
iew (iii) has been the level at which the system as an AI 
( A system has been generally presented; this is the level at 
vhich the claim for generality of the underlying approach 
s made. All the excitement surrounding the “knowledge 
^base/inference engine” paradigm, and the idea that 
knowledge acquisition and explanation can be keyed to 
phenomena at the rule level, emphasizes that the level cor- 
responding (iii) has been the level of abstraction at which 
AI interest has been expressed, and claims of progress 
have been made. 


be said to be a search for the “Holy 
abstraction at which intelligence be- 
t behavior emerges. Above this level, 
icular pieces of knowledge of the task 


level are specific details of how 
implemented. For example, in a 
as Mycin. everyone would agree 
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What of the level corresponding to (ii)? We have for 
several years at Ohio Slate worked on the hypothesis that 
this is indeed an important level of abstraction for AI; 
and that knowledge representation, control regimes for 
problems solving, knowledge acquisition, and explanation 
all can be significantly advanced by looking at phenomena 
at this level. B. Chandrasekaran has put forth this view 
in 1, 4 . In this paper we give a critical analysis of an 
important part of A I, viz., know I edge- based reasoning, and 
propose that a point of view based on a particular level of 
abstraction corresponding to generic information 
processing tasks has a number of advantages both for 
clarity ol analysis and for system design. Tins is not 
pure theoretical speculation; researchers in our laboratory 
have built many systems and tools based on this 
framework. We wish to point to this level of abstraction 
as a productive level for concentration, and to indicate the 
conceptual advantages of it. Knowledge acquisition, sys- 
tem design, control of problem solving and generation of 
explanation ail are facilitated at the same time, indicating 
that there is a naturalness to looking at phenomena at 
this level. 
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Intuitively one thinks that there must be some com- 
monality of reasoning processes that characterize 
“diagnosis” as a generic activity, even across domains as 
different as medicine and mechanical systems. There 
should be control strategies and ways of using knowledge 
that are common to diagnostic reasoning as such, or at 
least typical of diagnostic reasoning. Similarly there 
should be common types of knowledge structures and con- 
trol strategies for, say, design as a kind of reasoning ac- 
tivity. Further, we expect that the structures and control 
regimes for diagnostic reasoning will be generally different 
from those for design reasoning. However, when one looks 
at the formalisms (or equivalently the languages or shells), 
that are commonly used in expert system design, the 
knowledge representation and control regimes do not typi- 
cally capture these distinctions. For example, in diagnos- 
tic reasoning, one might generically wish to speak in term* 
of malfunction hierarchies, rule-out strategies, setting up a 
differential, etc., while for design, the generic terms might 
be device/component hierarchies, design plans, ordering of 
design subtasks, etc. Ideally one would like to represent 
diagnostic knowledge in a domain by using the vocabulary 
that is appropriate for the task. But typically the lan- 
guages in which the expert systems have been imple- 
mented have sought uniformity across tasks, and thus 
have lost clarity of representation at the task level. The 
coniputatjpnaj universality of representation languages such 
as Emycin or OPS5 - i.e., the fact that any computer 
program can in principle He written in these languages ~ 
often confuses the issue, since after the system is finally 
built it is often unclear which portions of the system 
represent domain expertise, and which are programming 
devices. In addition, the control regimes that these lan- 
guages come with (such as forward or backward chaining) 
do not explicitly indicate the real control structure of the 
system at the task level. For example, the fact that Hi 
5 performs a linear sequence of subtasks - an atypically 
simple strategy for design problem solving — is not ex- 
plicitly encoded; the system designer so to speak 
“encrypted” this control in the pattern-matching control of 
OPS5. 

These comments need not be restricted to the rule-based 
framework. One could represent knowledge as sentences in 
a logical calculus and use logical inference mechanisms to 
solve problems; or one could represent it in a frame 
hierarchy with procedural attachments in the slots. (It is 
a relatively straightforward thing, e.g, to rewrite MYCIN 
h in this manner, see'.) In the former, the control issues 
would deal with choice of predicates and clauses, and in 
the latter, they will be at the level of which links to pur- 
sue for inheritance, etc. None of these have any natural 
connection with the control issues specific to the task. 

The other side of the coin, so to speak, regarding con- 
trol is the following; because of the relatively low level of 
abstraction relative to the information processing task, 
there are control issues that are artifacts of the represen- 
tation, but often in our opinion misinterpreted as issues at 
the “knowledge-level.” K.g., rule-based approaches often 
concern themselves with conflict resolution strategies. If 
the knowledge were viewed at the level of abstraction ap- 
propriate to the task, often there will be organizational 
elements which would result in only a small set of highly 
relevant pieces of knowledge or rules to being brought up 
for consideration, without any conflict resolution strategies 
being needed. Of course, these organizational constructs 


could be “programmed” in the rule language, but because 
of the status assigned to the rules and their control as 
knowledge-level phenomena (as opposed to the implemen- 
tation level phenomena, which they often are), knowledge 
acquisition is often directed towards (typically syntactic) 
strategies for conflict resolution, whereas the really opera- 
tional expert knowledge is at the organizational level. 

This level problem with control structures is mirrored in 
the relative poverty of know ledge- level primitives for 
representation. For example the epistemology of rule sys- 
tems is exhausted by data patterns (antecedents or 
subgoals) and partial decisions (consequents or goals), that 
of logic is similarly exhausted by predicates, functions, in- 
ference rules, and related primitives. If one wishes to talk 
about types of goals or predicates In such a way that con- 
trol behavior can be indexed over this topology, such a 
behavior can often be programmed into these systems, but 
no explicit rendering of them is possible. E.g., Clanrey 
* found in his work using Mycin to teach students that 
for explanation he needed to attach to each rule in the 
Mycin knowledge base encodings of types of goals so that 
explanation of its behavior can be couched in terms of 
this encoding, rather than only in term of “Because 
was a subgoal of - This is not to argue that rule 

representations and backward or forward chaining control* 
are not “natural” for some situations. If all that a 
problem solver has for knowledge in a domain is in the 
form of a large collection of unorganized associative pat- 
terns, then data-directed or goal-directed associations may 
be the best that the agent can do. But that is precisely 
the occasion for weak methods such as hypothesize and 
match (of which the above associations are variants), and. 
typically, successful solutions cannot be expected in com- 
plex problems without combinatorial searches. Generally, 
however, expertise can be expected to consists of much 
more organized collections of knowledge, with control be- 
havior indexed by the kinds of organizations and forms of 
knowledge in them. 

Thus, there is a need for understanding the generic in- 
formation processing tasks that underlie knowledge-based 
reasoning. Knowledge ought to be directly encoded at the 
appropriate level by using primitives that naturally 

describe the domain knowledge for a given generic task. 
Problem solving behavior for the task ought to be con- 
trolled by regimes that are appropriate for the task. If 
done correctly, this would simultaneously facilitate 

knowledge representation, problem solving, and explana- 
tion. 

At this point it will be useful to make further distinc- 
tions. Typically many tasks that we intuitively think of 
as generic tasks are really complex generic tasks. I. e.. 
they are further decomposable into components which are 
more elementary in the sense that each of them has a 
more homogeneous control regime and knowledge struc- 
tures. For example, what one thinks of as the diagnostic 
task, while it may be generic in the sense that the task 
may be quite similar across domains, it is not a unitary 
task structure. Diagnosis may involve classiflcatory 
reasoning at a certain point, reasoning from one datum to 
another datum at another point, ami abduclive assembly 
of multiple diagnostic hypotheses at another point. 
Hierarchical classification has a different form of knowledge 
and control behavior from those for data-to-data reasoning, 
which in turn is dissimilar in these dimensions from as- 
sembling hypotheses. Our research focuses on tasks at 
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both these levels, but the latter are viewed as somewhat 
“atomic” tasks into which more complex, but still generic, 
tasks such as diagnosis and design can often be decom- 
posed. 

To summarize the view presented so far: There is a need 
for understanding the generic information processing tasks 
that underlie know ledge- based reasoning. Knowledge ought 
to be directly encoded at the appropriate level by using 
primitives that naturally describe the domain knowledge 
for a given generic task. Problem solving behavior for the 
task ought to be controlled by regimes that are ap- 
propriate for the task. If done correctly, this would 
simultaneously facilitate knowledge representation, problem 
solving, and explanation. 

Over the years, we have identified, and built systems 
using, six such generic tasks. Our work on MDX 0, ,0 . 
e.g., identified hierarchical classification, 

knowledge-directed information passing. and 
hypothesis matching as three generic tasks, and showed 
how certain classes of diagnostic problems can lx* imple- 
mented as an integration of these generic tasks. Since 
then we have identified several others: object synthesis 
by plan selection and refinement 11 , state 
abstraction 4 , and abductive assembly of 
hypotheses 1 *. There is no claim that these six are ex- 
haustive; in fact, our ongoing research objective is to iden- 
tify other useful generic tasks and understand their 
knowledge representations and strategies for control of 
problem solving. 

Some Generic Tasks 

Characterization of Generic Tasks 

Each generic task is characterized by: a task 

specification in the form of generic types of input and 
output information; specific forms of knowledge needed 
for the task, and specific organization of knowledge 
particular to the task; a family of control regimes that 
are appropriate for the task. 

A task-specific control regime comes with certain charac- 
teristic types of strategic goals. These goal types will 
play a role in providing explanations of its problem solv- 
ing behavior. 

When a complex task is decomposed into a set of 
generic tasks, it will in general be necessary to provide for 
communication between the different structures specializing 
in these different types of problem solving. Also there is 
not necessarily a unique decomposition. Depending upon 
the availability of particular pieces of knowledge, different 
architectures of generic tasks will typically be possible for 
a given complex task. 

We will now give brief characterizations of the generic 
tasks that we have identified. 

Taxonomic Classification 

Task specification: Classify a (possibly complex) descrip- 

tion of a situation as an element, as specific as possible, 
in a classification hierarchy. E.g. classify a medical case 
description as an element of a disease hierarchy. 


Forms of knowledge: one main form is < partial situa- 

tion description > — > evidence /belief about confirmation 
or disconfinnation of classificatory hypotheses. E.g., in 
medicine, a piece of classificatory knowledge may be: cer- 
tain pattern in X-ray & bilirubin in blood — > high 
evidence for cholestasis. 

Organization of knowledge: knowledge of the form above 
distributed among concepts in a classificatory concept 
hierarchy. Each conceptual “specialist” ideally contains 

knowledge that helps it determine whether it (the concept 
it stands for) can be established or rejected. 

Control Regime: Problem solving is top down, each con- 
cept when called upon tries to establish itself. If it suc- 
ceeds, it lists the reasons for its success, and calls its suc- 
cessors, which repeat the process. If a specialist fails in 
its attempt to establish itself, it rejects itself, and all its 
successors are also automatically rejected. This control 
strategy can be called Establish- Refine, and results in a 
spec i He classification of the case. (The account is a 

simplified one. The reader is referred to 10 for details and 
elaborations.) 

Goal types: E.g., Establish <concept>, Refine 

(subclassify) <concept> 

Example Use: Medical diagnosis can often be viewed as 

a classification problem. In planning, it is often useful to 
classify a situation as of a certain type, which then might 
suggest an appropriate plan. 

Object Synthesis by Plan Selection and Refinemen t 

Task Specification: Design an object satisfying specifica- 

tions (object in an abstract sense: they can be plans, 
programs, etc.). 

Forms of knowledge: Object structure is known at some 

level of abstraction, and pre-compited plans are available 
which can make choices of components, and have lists of 
concepts to call upon for refining the design at that level 
of abstraction. 

Organization of Knowledge: Concepts corresponding to 
components organized in a hierarchy mirroring the object 
structure. Each concept has plans which can be used to 
make commitments for various '‘dimensions” of the com- 
ponent. 

Control Regime: Top down in general. The following is 
done recursively until a complete design is worked out: A 
specialist corresponding to a component of the object is 
called, the specialist chooses a plan based on the specifica- 
tions and problem state, instantiates and executes the plan 
which suggests further specialists to call to set details of 
the subcomponents. Plan failures are passed up unli! ap- 
propriate changes are made by higher level specialists. 

Goal Types: E.g., Choose plan, execute plan element •. 
refine <plan>, redesign (modify) partial design * to 
respond to failure of '.subplan. *, select alternative plan, 
etc. 

Example: Expert design tasks, routine synthesis of plans 

of action. 

We will characterize the other generic tasks more suc- 
cinctly. The reader is referred to 1 for more details. 
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Knowledge-Directed Information P assing 

Task: It is desired to obtain attributes of some datum, 
by deriving from some conceptually related datum. Some 
forms of knowledge are: <attribute> of <datum> is in- 

herited from < attribute > ijnM parent of <datum>, 
<attribute> of <datum> is related as <relation> to 
<attribute> of <concept>. Organization: concepts are or- 
ganized as a frame hierarchy * with IS- A and PART-0 F 
links. Each frame is a specialist in knowledge-directed 
data inference for the concept. This is basically a hierar- 
chical information-passing control regime. 

Example uses: knowledge-based data retrieval tasks in 
wide variety of situations, as an intelligent data base in 
support of problem solvers of other types. 

Abductivc Assembly of Explana tory Hypotheses 

Task Specification: Given a situation (described by a set 
of data items) to be explained by the best explanatory ac- 
count, an d 0 iven a number of h) t . theses, each associated 
with a degree of belief, and each of which offers to ex- 
plain a portion of the data (possibly overlapping with data 
to be accounted for by other hypotheses), construct the 
best composite explanatory hypothesis. Some forms of 
knowledge are: causal or other relations (e.g. special case 
of, incompatibility, suggestiveness) between the hypotheses, 
relative significance of data items, and ways to group data 
items to be explained. Organization: one main, or a 
hierarchical community of active abducers, each specializ- 
ing in explaining a certain portion of the data by compos- 
ing and criticizing hypotheses. Control Regime: (See 

13 for a fuller discussion.) A specialized means-ends 
regime is in control, driven by the goals of explaining all 
the significant findings, with an economical hypothesis, 
which is consistent, and has been criticized for certain 
strengths and weaknesses. Some goal types are: account- 
for <datum,': check-superfluousness-of v hypothesis >. 

choose the most significant unexplained finding. The In- 
ternist system 11 and the Dendral system 15 perform abduc- 
tive assembly as part of their problem solving. 

St ate Abst raction 

Task Specification: Given a change in some state of a 
system, provide an account of the changes that can be ex- 
pected in the functioning of the system. (Useful for 

reasoning about consequences of changes on complex 
systems.) One knowledge form is * change in state of 

subsystem> — "> - change in functionality of subsystem - 
change in state of the immediately larger system The 

knowledge is organized into conceptual specialists cor- 
responding to systems and subs) stems connected in a way 
mirroring the way the systems and subsystems are put 
together. The control is basically bottom up. following 

the architecture of the system/ subsystem relationship. 
The changes in stales are followed through, interpreted as 
changes in functionalities of subsystems, until the changes 
in the functionalities at the level of abstraction desired are 
obtained. This form of reasoning is useful for answering 
questions like: **What system functionalities will be com- 
promised if this valve fails closed?’’. 

Hypothesis Matchi ng 

Given a concept and a set of data that describe the 
problem state, decide if the concept matches the situation. 
The idea here is to encode the routine knowledge for 


verification and refutation that the concept applies to the 
situation. One way this can be done is by using a hierar- 
chical representation of evidence abstractions, where the 
top node determines the overall degree of matching of the 
hypothesis to the data, and lower-level nodes represent 
components or features of evidence for the evidence 
abstraction at higher levels. Form of knowledge are such 
as to enable evaluation of strength for each evidence 
abstraction, and to support mapping degrees of belief ;r 
each of these evidence abstractions, to degree of belief in 
the higher abstractions. Strength for an evidence abstrac- 
tion can be determined Each evidence abstraction can be 
determined by matching against prototypical patterns 
which have evidential significance. Samuel’s sigruUutt 
tables can be thought of as performing this task. 

How Existing Expert Systems can be Analysed In 
This Framework 

Separating the implementation language and the intrinsic 
nature of the tasks has been argued as being salutary for 
a number of reasons. Let us look at some of the better 
known expert systems from the perspective of the 
framework developed so far in this paper. 

MYCJN’s task is to (i) classify a number of observations 
describing a patient's infection as due to one or another 
organism, and (ii) once that is done, to instantiate a plait 
with parameters appropriate for the particular patten* 
situation. We have shown in lt * how the diagnostic portion 
of MYCIN can be recast as a classification problem solver, 
with a more direct encoding of domain knowledge and a 
control structure that is directly appropriate to this form 
of problem solving. 

Prospector 17 classifies a geological description as one of a 
p re-enumerated set of formations. Internist 14 generates 
candidate hypotheses by a form of enumeration 
(plausibility scoring and keeping only the top few) and 
uses a form of abductive assembly to build a composite 
hypothesis that accounts for all of the data. Assembly 
and hypothesis enumeration alternate. Dendral 15 generates 
candidate hypotheses by a form of hypothests matching and 
uses a form of abductive assembly which puts together the 
best molecular hypothesis from the fragments produced by 
the matching process. 

Note that in these analyses we have not mentioned rules 
(Mycin), networks (Prospector), graphs (Dendral), etc., 
which are the means of encoding and carrying out the 
tasks. This separation is an essential aspect of what we 
mean by the “right” level of abstraction in analysis. 

Encoding Knowledge at the Level of the Task: 

The Generic Task Toolset 

For each generic task, the form and organization of the 
knowledge directly suggests the appropriate representation 
in terms of which domain knowledge for that task can be 
encoded. Since there is a control regime associated with 
each task, the problem solver can be implicit in ;he 
representation language. That is, a shell for each generic 
task can be constructed such that, as soon as knowledge 
is represented in the shell, a problem solver which uses 
the control regime on the knowledge can be created by 
the interpreter. This is similar tn what representation 
systems such as KMYCIN do. hut note that we are 
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deliberately trading generality at a lower level to gain 
specificity, clarity, and richness of ontology and control at 
a higher level. 

We have designed and implemented representation lan- 
guages for versions of each of the six generic tasks we 
described. Here is a list of the generic task tools, each 
with a brief description of the task for which it is 
designed. 

• HYPER for matching concept to situation to 
determine confidence or appropriateness. 

• CSRL for taxonomic classification, typically a 
major component of diagnostic reasoning . 18 

• DSPL for object synthesis by plan selection 
and refinement, captures knowledge for certain 
routine design and planning tasks . 10 

• IDABLE for knowledge-directed information 
passing for intelligent data retrieval. 

• PEIRCE for assembly and criticism of com- 
posite explanatory hypotheses, a form of 
abduction or best-explanation reasoning . 20 

• WWHI (What Would Happen IQ for predic- 
tion by abstracting state changes. 

We have described how this approach directly helps in 
providing intelligible explanations of problem solving in ex- 
pert systems . 21 The approach has a number of other im- 
plications. E.g.. uncertainty Handling in problem solving is 
usefully viewed as consisting of different types for each 
kind of problem solving, rather than as a uniform general 
method .- 2 

In principle the tools can be used together to build com- 
posite problem solvers that integrate the different types of 
reasoning associated with the generic tasks. Systems have 
been built integrating more than one type of reasoning 
(the Red 21 system for example relies on four of the types) 
but these systems predate the availability of the tools. At 
present the actual toolset consists of separately imple- 
mented tools in a variety of languages: each tool having 
an incarnation in Interiisp. LAIR has under development 
an integrated version of the toolset in Common Lisp. 

The computational architecture of a problem-solving sys- 
tem (or system component) built with any of the tools is 
based on functionally distinct, highly modular elements, 
tightly organized. A generic task problem solver is a 
community of agents, where each agent is of a specific 
type, each has its own embedded knowledge. The agents 
are organized so that they have specific lines of com- 
munication with each other: and. depending on the generic 
task, they pass control around in a well-defined way in or- 
der to cooperate and solve the problem. A II YPER-built 
system is made up of knowledge groups, hierarchically or- 
ganized: a (.SRL-built system consists of a hierarchical 
community of classification specialist, each specializing in a 
single classificatory concept. This sort of system architec- 
ture. besides making implementation in an object-oriented 
programming framework fairly easy, makes for systems 
that are distributable and have predictable concurrencies. 
The high degree of modularity— modules having clear func- 
tions. and clear interactions with other modules— makes for 
good software engineering at the knowledge level, 
“structured programming of knowledge bases" if you will. 


DSPL for building a Million Planning Aislitant 

We will describe the use of DSPL (Design Specialists 
and Plans Language) for the design and implementation of 
an expert system in the domain of tactical air mission 
planning. After investigating K NO IIS system from 

MITRE Corporation, an existing mission planning system, 
we developed the Mission Planning Assistant (MPA) using 
DSPL and our generic task approach to building expert 
systems. KNOBS was the primary source of domain 
knowledge for the MPA system. Our project had two 

main goals. First, we wanted to explore the use of DSPL 

for routine planning tasks. Initially, DSPL was developed 
as a result of studying a routine mechanical design task . 11 
It seemed to us, however, that routine planning shares 

many of the characteristics of routine design, suggesting 
that they might require some of the same kinds of 

problem-solving activities. Secondly, we wanted to inves- 
tigate the explanation facilities that are necessary in plan- 
ning systems. We wanted to demonstrate that our generic 
task architectures provide very natural and comprehensive 
frameworks for explanation. 

Tactical mission planning in the Air Force essentially in- 
volves the assignment of resources to various tasks. The 
resources are primarily aircraft and their stores located at 
airbases across the theater of operations. The tasks are 
specified by an ” apportionment” order issued by the Joint 
Task Force Commander to a Tactical Air Control Center 
(TACO). This order describes the overall military objec- 
tives as determined by the Task Force Commander. The 
TACC is responsible for assigning aircraft and personnel 
from specific military units to meet the objectives of the 
apportionment order. The result of these assignments is 
an "Air Tasking Order” (ATO) which summarizes the 
responsibilities of each unit with respect to the day's mis- 
sions. Each mission planned requires attention to such 
details as the selection of aircraft type appropriate to the 
mission, selection of a base from which to fly the mission, 
and coordination with other missions. 

The MPA system we developed currently addresses onlv 
a single type of mission, the Offensive Counter-Air (OCA) 
mission. An OCA mission is an air strike directed specifi- 
cally against an enemy's airbase. Our selection of the 
OCA mission arose primarily because of the availability of 
the KNOBS system and its knowledge base of relevant 
domain facts. Our approach to tactical mission planning 
treats the Air Tasking Order (ATO) as an abstract device 
to be designed. The planning of the missions of the com- 
pleted ATO involves a process similar to the process a 
designer undergoes when faced with a complex mechanical 
device to design. A view of design problem solving should 
illuminate this idea. For a more comprehensive descrip- 
tion of design see 11 . 

Routine Design and DSPL 

The general domain of design is vast: it involves 
creativity, many different problem-solving techniques, and 
many kinds of knowledge. Goals are often poorly 

specified, and may change during the course of problem 
solving. A spectrum of classes of design problems can be 
discerned, varying in complexity from those problems re- 
quiring significant amounts of “creativity", to the most 
routine design problems requiring no creativity at ail. 
The complexity of a design problem will depend on what 
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pieces of knowledge are available to the problem solver 
prior to the start of design, that », the right pieces of 
knowledge can remove the need for creativity and turn a 
complex design task into a routine one. 

What we have called ''Class 3 Design** characterizes a 
form of routine design activity which postulates that 
several distinct types of knowledge are available prior to 
problem solving. First we assume that complete 
knowledge of the component breakdown of the to-be* 
designed device is available to the problem solver, includ- 
ing knowledge of what component attributes need to be 
specified in order to specify a design. The final design 
will consist only of components known in advance, and no 
novel components need to be synthesized. Secondly, we 
assume that knowledge is available in the form of plan 
fragments ({escribing the actions required to design each 
component. A plan for designing a component will typi- 
cally include the designing of subcomponents as steps in 
the plan. Thirdly, we assume that recognition knowledge 
is available that will allow the problem solver to select be- 
tween the alternative plans for designing a component, 
depending on the design requirements and the state of the 
problem solving. The problem solving proceeds by follow- 
ing a top-down process of plan selection and refinement, 
with localized back up and selection of alternative plans 
upon failure of a design plan at any level. While the 
choices at each point tnav be simple, the design process 
overall may be quite complex, and objects of significant 
complexity ran be designed. It appears that a significant 
portion of the everyday activity of practicing designers can 
be analyzed as class 3 design. 

In !)S|*L. a design problem solver consists of a hierarchy 
of cooperating, conceptual specialists, with each specialist 
responsible for a particular portion of the design. 
Specialists higher up in the hierarchy deal with the more 
general aspects of the device being designed, while 
specialists lower in the hierarchy design specific sub- 
portions of the device, or address other design suhtasks. 
Any specialist may access a design data-base (mediated by 
an intelligent data-base assistant). The organization of 

the specialists and the specific content of each one is in- 
tended to precisely capture the human designer’s expertise 
in the problem domain. Kach specialist in the design 
hierarchy contains locally the design knowledge necessary 
to accomplish that portion of the design for which it is 

responsible. There are several types of knowledge 

represented in each specialist, three of which are described 
here. First, explicit design plans in each specialist encode 
sequences of possible actions to successfully complete the 
specialist’s task. Different design plans within a specialist 
may encode alternative action sequences, but all of the 

plans within a particular specialist are always aimed at 
achieving the specific design goals of that specialist. A 
second type of knowledge encoded within specialists is en- 
coded in design plan sponsors. Kach design plan has an 
associated sponsor to determine the appropriateness of the 
plan in the run-tirne context. The third type of planning 
knowledge in a specialist is encoded in design plan selec- 
tors. The function of the selector knowledge is to ex- 
amine the run-time judgments of the design plan sponsors 
and determine which of the design plans within the 
specialist is most appropriate to the current problem con- 
text. 

Control in a USPL system proceeds downwards from the 
top-most specialist in the design hierarchy. Beginning 


with the top-moat specialist, each specialist aelects a 
design plan appropriate to the requirements of the 
problem and the current state of the solution. The 
selected plan is executed by performing the design actions 
specified by the plan. This may include computing and 
assigning specific values to attribute* of the device, check- 
ing constraint* to test the progress of the design, or in- 
voking sub-specialists to accomplish sub-portions of the 
design. Thus a design plan which refers to a sub- 
specialist is refined by passing control to that sub- 
specialist in its turn. DSPL also includes facilities for the 
handling of various types of plan failures, and for con trott- 
ing redesign suggested by such failures. 21 

Mission Planning as Routine Design 

We view tactical mission planning as predominantly a 
routine design task. The problem can be decomposed into 
the design of subcomponents of the mission plan, where 
each component can be designed in a fairly independent 
fashion. The Air Tasking Order is decomposed into 
various missions or groups of missions of known types. 
Each mission or group of missions can be planned rela- 
tively independently of the others, modulo resource conten- 
tion considerations. In both the mission planning and the 
mechanical design domains, each of the solutions to the 
subproblems must be appropriately combined into the 
solution for the problem which they decompose. Due to 
the well known limitations of human problem solving 
capacities, it is apparent that a human problem solver can 
be successful in such a situation only to the extent that 
she can decompose the problem into a manageable number 
of somewhat independent sub-problems, which can be 
solved separately and combined into a final solution. The 
MPA system uses DSPI, as a natural mechanism for 
representing the necessary knowledge. 

The MPA System 

The MI’ A system contains six specialists. The topmost 
specialist, OCA, accepts the mission requirements and ul- 
timately produces the Pinal mission plan. The OCA 
specialist divides its work between two subspecialists, base 
and aircraft. The base specialist is responsible for select- 
ing an appropriate base, while the aircraft specialist selects 
an aircraft type. The aircraft specialist has three sub- 
specialists, one for each of three aircraft types known to 
the MPA system. As needed, one of these specialists will 
select an appropriate configuration for its aircraft type. 

Problem solving begins when the OCA specialist is re- 
quested to plan a mission. Currently, the OCA specialist 
contains only a single design plan which first requests the 
base specialist, to determine a base, and then requests the 
aircraft specialist to determine (and configure) an ap- 
propriate aircraft for the mission. The current has* 
specialist simply selects a base from a list of candidate 
bases geographically near the target. The airrraft 
specialist uses considerations of threat types and weather 
conditions at the target to select an appropriate aircraft 
type and number for the mission. The aircraft specialist 
and its three configuration su Imperialists represent the 
most elaborated domain knowledge in the MPA system. 

Suppose the mission requirements call for a night raid. 
The plan sponsors for both the A- 10 arid F-l would rule 
out the possibility of using these aircraft, since (in our 
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domain model) neither of t hese aircraft have night flying 
capability. The F- 1 1 1 plan sponsor, since it is an all- 
weather filter with night capabilities, would not be ex- 
cluded. The plan sponsor for the F-lll, based on this 
and other considerations (range, ability to carry ap- 
propriate ordinance, target characteristics, etc.) would find 
the F-Ill suitable for the mission. The plan selector in 
the aircraft specialist, finding that two design plans have 
ruled out, would select the “suitable" F-lll design plan, 
and return this information to the specialist. The 
specialist executes the F-lll design plan, which includes 
setting the aircraft type in the mission template to 
“F*lir\ and invoking the F-lll configuration specialist 
which in turn decides an acceptable ordinance load for the 
F-lll for this mission. Once the configuration of the 
aircraft is known, the single aircraft probability of destruc- 
tion in the mission context can be computed. Finally, 
knowing the mission capabilities of each aircraft, the re- 
quired number of aircraft can be determined in order to 
achieve the required probability of destruction, and the 
necessary number of aircraft can be reserved from the 
proper unit. 

Summary 

We have argued the need for high-level task -specific tools 
for constructing know ledge- based problem-solving systems. 
We described our approach, based on the notion of generic 
information processing tasks, and described a toolset which 
can be used to efficiently build expert systems. Kxpert 
systems built according to this methodology have all of 
the ad vantages of control strategies and knowledge 
representations that are especially suited to their infor- 
mation processing tasks. Advantages include knowing 
what kinds of knowledge to collect, and where to put it 
away for use in the problem solver, efficient processing at 
run time, and explanations of system behavior in terms of 
strategies and problem solving goals keyed to the type of 
reasoning. We have illustrated the power of these ideas 
by paying special attention to a high level language called 
l)SPL, and have shown how it was used in the construc- 
tion of a system called MPA. for assisting with mission 
planning in the domain of offensive counter air missions. 
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